[codex] fix runtime guard stale log filtering#226
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 709468fd29
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| matches = [ | ||
| service_since | ||
| for service, service_since in service_since_by_name.items() | ||
| if any(alias and alias in job_name for alias in _service_job_aliases(service)) |
There was a problem hiding this comment.
In multi-service runtime guards where one service alias is a substring of another service's scheduler job, this substring match can associate a job with multiple services and then max(matches) uses the newest unrelated revision window. For example, charles-schwab-live-u7654-mega-service-scheduler also matches the alias charles-schwab derived from charles-schwab-service; if that shorter service was deployed later, legitimate scheduler failures for the live service before that timestamp are skipped as stale. The scheduler entry should resolve to the best/exact owning service rather than every substring alias.
Useful? React with 👍 / 👎.
| for key in ("runtime_target_enabled", "RUNTIME_TARGET_ENABLED"): | ||
| if key in target: | ||
| return _coerce_bool(target.get(key), True) | ||
| if key in runtime_target: | ||
| return _coerce_bool(runtime_target.get(key), True) |
There was a problem hiding this comment.
When CLOUD_RUN_SERVICE_TARGETS_JSON uses the same per-target shape accepted by scripts/build_cloud_run_env_sync_plan.py ({"env": {"RUNTIME_TARGET_ENABLED": "false"}}), _target_enabled() still returns true because it checks only the top-level target and runtime_target object. _load_services() then includes that disabled service via the target's service_name, so the guard continues querying and alerting on services the sync plan marks disabled; include the target env mapping when evaluating the flag.
Useful? React with 👍 / 👎.
1 participant
Summary
Test Plan